End of ck patchset
=The end of the -ck kernel set of patches - Brief introduction= At least as of "Mon May 14 20:23:42 EST 2007", maintainer of the -ck set of kernel patches, Con Kolivas, decided to discontinue the -ck patchset. This is the date when his kernel patch homepage was last updated. The following message can be seen (at least on 06/18/07, 2:00 PM GMT+0) on the -ck patchset homepage: "2.6.22-ck1 will be the last -ck ever" =Further Information and Possible Reasons= Further Information on the -ck author's decision The gmane.linux.kernel.ck mailing list Apparently, the -ck patchset was discontinued due to the personal dissatisfaction of its author with recent events' development around the mainline Linux kernel. Further information can be found on this mailing list: http://news.gmane.org/gmane.linux.kernel.ck It is advisable to pay attention to the opinions of the main participants in the recent mild conflict about a piece code from the mainline kernel (the CPU scheduler) being developed. These are: Con Kolivas, Ingo Molnar, Linus Torvalds. Who is who? * Mr. Con Kolivas: author of the -ck patchset. * Mr. Ingo Molnar: long-time maintainer of the mainline kernel CPU scheduler. * Mr. Linus Torvalds: Founder of Linux, has a (very) strong voice in kernel discussions. The Linux Kernel Mailing List (the LKML) Try searching the Linux Kernel Mailing List to get archives of the original discussion. The IRC channel for the -ck patchset Join IRC: irc.oftc.net #ck to (possibly) discuss this and other issues. Possible Reasons for the -ck author's decision Possible reasons for Mr. Kolivas' decision have been summarized by him in [http://article.gmane.org/gmane.linux.kernel.ck/7850 this post on the gmane.linux.kernel.ck mailing list: Quoting Mr. Con Kolivas "1. If whatever performance advantage it has is all but abolished compared to mainline then there is no point maintaining alternate patches to achieve the same endpoint. 2. All interest I have in kernel development, even out of the mainline spotlight, has been... abolished (I had nastier words but decided not to use them.) It is clear that I cannot develop code for the linux kernel intended only to be used out of mainline and not have mainline get involved somewhere along the line. Whether it be the users or even other developers repeatedly asking "when will this be merged". This forever gets me into a cycle of actually trying to merge the stuff and ... well you all know what happens at that point (again I had nastier words but decided not to use them.) So, I've had enough. I'm out of here forever. I want to leave before I get so disgruntled that I end up using windows." /Quoting Mr. Con Kolivas Mr. Kolivas has also provided his reasons in a lengthy interview at APC Magazine, where he cites the loss of fun because of the current situation as the main reason for ending his activity. A brief summary of the conflict on the mainline kernel CPU scheduler Mr. Kolivas has developed a surprisingly efficient piece of code, the Staircase-Deadline CPU scheduler (citation needed !). It is claimed to be able to completely substitute the mainline kernel CPU scheduler, maintained by Mr. Ingo Molnar. Despite the rave reviews Mr. Kolivas' code has collected, the kernel developers (including, but not only, Mr. Linus Torvalds) have been reluctant to the change. Mr. Ingo Molnar has then begun to rapidly develop and enhance his own version of the disputed code, CFS, sometimes using ideas (but giving credit) from Mr. Kolivas' Staircase-Deadline (SD). Mr. Molnar's code has been included in mainline Linux kernel after a very short review period. This may have been a strong reason for Mr. Con Kolivas to abandon his patchset. A lot has been discussed on the point, which code is better (including, but not limited to terms of performance). Also, letting the user choose the CPU scheduler at build time (and thus, including both versions of this code for the time being) has been topic of discussion on the Linux Kernel Mailing List. At the time of writing (06/18/07), this idea seems to not be considered seriously by the kernel maintainers.